Started test build 177191

Build 177191 failed

Started test build 177192

Build 177192 failed

Started test build 177194

Build 177194 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/160347/org.virt_manager.virt_manager.Extension.Qemu.flatpakref

Alright. Everything works with workarounds up until

This might require another patch like https://github.com/flathub/org.virt_manager.virt-manager/blob/master/libvirt-use-monitor-in-xdg-runtime-dir.patch on libvirt 😭

Both of these need to be patched so that this will work
https://github.com/libvirt/libvirt/blob/72142dcde34dd7e1dfb3ea0d841f567badd80539/src/qemu/qemu_virtiofs.c#L74
https://github.com/libvirt/libvirt/blob/72142dcde34dd7e1dfb3ea0d841f567badd80539/src/qemu/qemu_domain.c#L10564

🚧 Test build enqueued.

🚧 Started test build.

🚧 Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/185165/org.virt_manager.virt_manager.Extension.Qemu.flatpakref

Hi, thanks for your hard work on this! The error you're seeing is the dreaded 107 character UNIX socket path limitation. In your case the path /var/home/tulip/.var/app/org.virt_manager.virt_manager/config/libvirt/qemu/lib/domain-6-achillobator/fs0-fs.sock is 112 chars long, have you tested if it would work with a slightly shorter VM name? Of course this isn't ideal, since even the length of one's username affects whether this is usable or not, but least it would enable further evaluation. I will be testing this shortly.

Its been quite a while since I've worked on this pull request, but patching this, just like we've done with Libvirt, might be the way to go! Please report back if you get anything successful :)

bot, build

🚧 Test build enqueued.

🚧 Started test build.

❌ Test build failed.

I did now manage to rebase this atop master and run some additional tests, but it seems that even with shorter paths we unfortunately hit a bunch of other challenges:

• virtiofsd is not in PATH, but this can be worked around by adding <binary path="/app/lib/extensions/bin/virtiofsd"/> to the filesystem configuration of the VM
• Next, virtiofsd as configured by libvirt is using the namespace sandboxing method, expecting /etc/subuid and /etc/subgid to be present. This won't work inside a Flatpak. While virtiofsd has a none sandbox option, it's not an option in the libvirt schema. I worked around this using a wrapper script, since the virtiofsd seems to respect the last option it's given enabling us to override it. Note that libvirt still requires /etc/subuid and /etc/subgid to be present, but they can be empty.
• Ultimately, the attempt ends in a "Connection refused" as libvirt attempts to connect to the virtiofsd socket. From what I can tell, virtiofsd is never launched, and for some reason it also doesn't work if I launch it by hand inside the Flatpak: libvirt still can't connect to the socket.

This is as far as I managed to look into it, step 1 would likely be to add the none sandbox option to libvirt if there are some other underlying assumptions it makes wrt. namespaces that break the functionality here.